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GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/kev . 
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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile 
Termination (MT) which enables the attachment of synchronous terminals to a MT within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines Terminal Adaptation Functions (TAF) which are integrated in a Mobile Termination 
(MT) and which enable the attachment of Synchronous Terminals to an MT (see GSM 04.02 [3]). The general aspects 
of Terminal Adaptation Functions are contained in specification 3G TS 27.001 [9]. The present document covers 
support of synchronous data services (see 3G TS 22.002 [6]) for the following interfaces and procedures: 

- V.22[15] DTE/DCE Interface; 

- V.22bis[16] DTE/DCE Interface; 

- V.26 ter [19] DTE/DCE Interface; 

- X.21 bis [24] DTE/DCE Interface; 

- X.32 [30] Procedure; 

- V.25bis[18] Procedure; 

LAPB is the only synchronous non-transparent protocol which is considered in the present document. 

NOTE: From GSM R99 onwards the following services are no longer required by a GSM PLMN: 

the dual Bearer Services "alternate speech/data" and "speech followed by data"; 

the dedicated services for PAD and Packet access; 

- BS21 ... 26andBS31 ...34. 

The support of these services is still optional. The specification of these services is not within the scope of the present 
document. For that, the reader is referred to GSM Release 98. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 03.10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) connection types". 

[3] GSM 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) access reference configuration". 

[4] GSM 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Mobile 

Station - Base Station System (MS - BSS) interface". 

[5] GSM 08.20: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Base 

Station System - Mobile-services Switching Centre (BSS - MSC) interface". 

[6] 3G TS 22.002: "Circuit Bearer Services (BS) supported by PubUc Land Mobile Network 

(PLMN)". 
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[7] 3G TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols-Stage 3". 

[8] 3G TS 24.022: "Radio Link Protocol (RLP) for Circuit Switched Bearer and Teleservices". 

[9] 3G TS 27.001 : "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[10] 3G TR 21.905: "3G Vocabulary". 

[11] ITU-T Recommendation 1.420 (1998): "Basic user-network interface". 

[12] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call 

control". 

[13] ITU-T Recommendation V.IO: "Electrical characteristics for unbalanced double-current 

interchange circuits operating at data signalling rates nominally up to 100 kbit/s". 

[14] ITU-T Recommendation V.l 1: "Electrical characteristics for balanced double-current interchange 

circuits operating at data signalling rates nominally up to 10 Mbit/s". 

[15] ITU-T Recommendation V.22 (1988): "1200 bits per second duplex modem standardized for use 

in the general switched telephone network and on point-to-point 2-wire leased telephone-type 

circuits". 

[16] ITU-T Recommendation V.22 bis (1988): "2400 bits per second duplex modem using the 

frequency division technique standardized for use on the general switched telephone network and 
on point-to-point 2-wire leased telephone-type circuits". 

[17] ITU-T Recommendation V.24 (1996):"List of definitions for interchange circuits between data 

terminal equipment (DTE) and data circuit-terminating equipment (DCE)". 

[18] ITU-T Recommendation V.25 bis (1996): "Synchronous and asynchronous automatic dialling 

procedures on switched networks". 

[19] ITU-T Recommendation V.26 ter (1988): "2400 bits per second duplex modem using the echo 

cancellation technique standardized for use on the general switched telephone network and on 
point-to-point 2-wire leased telephone-type circuits". 

[20] ITU-T Recommendation V.28 (1993): "Electrical characteristics for unbalanced double-current 

interchange circuits". 

[21] ITU-T Recommendation V.32 (1993): "A family of 2-wire, duplex modems operating at data 

signalling rates of up to 9600 bit/s for use in the general switched telephone network and on leased 
telephone -type circuits". 

[22] ITU-T Recommendation V. 1 10 (1996): "Support of data terminal equipments with V-Series 

interfaces by an integrated services digital network". 

[23] Void. 

[24] Void. 

[25] ITU-T Recommendation X.24 (1988): "List of definitions for interchange circuits between Data 

Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) on public data 
networks". 

[26] ITU-T Recommendation X.26 (1993): "Electrical characteristics for unbalanced double-current 

interchange circuits operating at data signalling rates nominally up to 100 kbit/s". 

[27] ITU-T Recommendation X.27 (1996): "Electrical characteristics for balanced double-current 

interchange circuits operating at data signalling rates up to 10 Mbit/s". 

[28] Void. 

[29] Void. 
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[30] ITU-T Recommendation X.32 (1996): "Interface between Data terminal Equipment (DTE) and 

Data Circuit-terminating Equipment (DCE) for terminals operating in packet mode and accessing a 
Packet-Switched Public Data Network through a public switched telephone network or an 
Integrated Services Digital Network or a Circuit-Switched Public Data Network". 

[31] ISO Recommendation 8885: "Information technology - Telecommunication and information 

exchange between systems - High-level data link control (HDLC) procedures - General purpose 
XID frame information field content and format" . 

[32] ISO Recommendation 8886: "Information technology - Telecommunication and information 

exchange between systems - Data link service definitions for Open Systems interconnection". 

[33] Personal Computer Memory Card Association: "PCMCIA 2. 1 or PC -Card 3.0 electrical 

specification or later revisions". 

[34] Infrared Data Association IrDA: "IrPHY Physical layer signalling standard". 

[35] 3G TR 23.910: "Circuit Switched Data Bearer Services". 

2.1 Abbreviations 

In addition to the abbreviations listed below, the present document also uses termslisted in 3GTR 21.905 [10] and 
GSM 01.04 [1]. 

AU Access Unit 

BORE Bit Oriented Relay Entity 

EDGE Enhanced Data for Global Evolution 

FES For further studies 

IrDA Infrared Data Association 

IrPHY InfraredPHYsical layer 

ITU-T ITU-Telecommunication Standardization Sector 

MUX Multiplexer 

PCMCIA Personal Computer Memory Card Association 

PC Personal Computer 

2.2 Definitions 

The term 'mobile station' ( MS ) in the present document is synonymous with the term 'user equipment' (UE ) in 3G 
terminology as defined in 3G TR 21.905. 

The term 'TE2' in the present document is synonymous with the term 'TE' in 3G terminology as defined in 
3GTR 21.905. 

The term 'MT2' in the present document is synonymous with the term 'MT' in 3G terminology as defined in 
3GTR 21.905. 



3 General 

3.1 Customer access configuration 

The PLMN access reference configuration is described in figure 1 of GSM 04.02 [3] and 3G TS 27.001 [9]. The present 
document specifically refers to the MTs which support terminal equipments (TEl or TE2) that use synchronous bearer 
capabilities. 
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3.2 Terminal Adaptation Function 



The TAF is functionally part of an MTO, MTl or MT2 (see GSM 04.02 [3]). The terminal adaptation provides facilities 
to allow manual or automatic call control functions associated with circuit switched data services, in case of ITU-T V 
series interfaces. The following functions are included: 

Editor's note: V.25bis is outdated. References to V.25 bis procedures need to be replaced by corresponding 

procedures based on V.250 and 3G TS 27.007.- conversion of electrical, mechanical, functional and procedural 
characteristics of the ITU-T V-series, type interfaces to those required by a PLMN; 

- bit rate adaptation of ITU-T V-series and ITU-T X-series data signalling rates and the ISDN 64 kbit/s to that 
provided in the GSM PLMN; 

- the mapping of ITU-T V.25 bis [18] AUTO CALL/AUTO ANSWER procedures to the PLMN Layer 3 
signalling; 

the mapping functions necessary to convert ITU-T S-interface signalling to PLMN Layer 3 signalling; 

synchronization procedure, which means the task of synchronizing the entry to and the exit from the data transfer 
phase between two subscriber terminals. This is described in the specification 3G TS 27.001 [9]; 

filtering of channel control information. This is described in the specification 3G TS 27.001 [9]; 

- compatibility checking (see 3G TS 27.001 [9]); 
layer 2 relaying (see annex 1); 

flow control; 

in Call Modification function (see clause 4); 

splitting and combining of the data flow in case of multi substream data configurations. 

3.3 TAF Interfacing to other MT functions 

TAP interfacing is shown in figure 1 . 



TAF 




Mobility Management 










RR Management 










Channel Codec FEC 





MMI 



Call Control 



Figure 1 : TAF interfacing to other lUIT functions 



4 Terminal Adaptation Functions for synchronous 

transparent services 

Specification GSM 03.10 [2] refers to the models for connection types supporting synchronous transparent services. 
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4.1 Rate Adaptation in GSIVI 



Rate adaptation on the MS-BS interface is described in GSM 04.21 [4]. The synchronous data services make use of the 
following rate adaptation functions: RAl, RA2, RAl/RAl', RAl' and in case of TCH/F28.8 usage, EDGE-MUX. See 
also figures 6, 7 and 8 in GSM 03.10 [2]. The D-bits of the rate adaptation frames are used to convey user data and the 
S- and X-bits are used to convey channel status information associated with the data bits in the data transfer state, or to 
carry substream numbering between the Split/Combine functions in case of mult substream operation. For the S- and 
X-bits, a ZERO corresponds to the ON condition, a ONE to the OFF condition. 



4.1 .1 Rate adaptation - ITU-T V-series 



This is provided as indicated in specification GSM 04.21 [4]. The functions applied in this case are shown in figure 2 
(see model 2b in figures 6, 7 and 8 of GSM 03.10 [2]). 





Interface circuits 
(data and control) 




MT2 




TE2 
V-series 






RAl' 




R 











Figure 2: Rate adaptation for V-series terminals 

4.1 .2 Rate adaptation - ITU-T X.21 

Void. 

4.1 .3 Rate adaptation - ITU-T S-interface 

Void. 

4.2 Interchange Circuit Signalling IVIapping 
4.2.1 ITU-T V-series interchange circuit mapping 

The interchange circuit signalling mapping at the interface between the TE2 and the MT shall conform to ITU-T 
recommendation V.24 [17]; while the signal levels at the interface shall conform either to ITU-T recommendation 
V.28 [20], or to IrDA IrPHY Physical signalHng standard specification [34], or to PCMCIA 2.1 [33], or to 
PC -Card 3.0 [33] electrical specifications or to later revisions. 

The signals required at this interface are shown in table 2. 

Specification GSM 04.21 [4] refers to the frame structure and identifies the use of status bits for the carriage of 
signalling information. 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 1 shows the mapping scheme between the ITU-T V.24 [17]circuit numbers and the status bits for 
the transparent mode. It also shows how the unused status bits should be handled. It is derived from the general 
mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in subsequent sections. 



£75/ 



3G TS 27.003 version 3.4.0 Release 1999 



11 



ETSI TS 127 003 V3.4.0 (2000-06) 



Table 1 : Mapping scheme at the IVIT for the transparent mode 



Signal at TE2/MT 

interface or condition 

within the lUIT 


■mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT 1 08/2 


not mapped (note 6) 




CT109 




from status bit SB (note 7) 


CT133 


not mapped (note 2) 




always ON 


to status bit SA (note 3) 




always ON 


to status bit SB (note 1) 




always ON 


to status bit X (note 4) 




ignored by IVIT 




from status bit SA (note 3) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (27.002, 
annex C), could be used to carry CT 105. However, CT 105 should 
always be ON in the data transfer state since only duplex operation is 
supported. Also, many DTEs use the connector pin assigned to CT 105 
for CT 1 33. No interchange circuit shall be mapped to the SB bit which 
shall always be set to ON in the data transfer state. 

NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. 

NOTE 3: The SA bits in both directions are available only with certain channel 
codings. Therefore, for maximum compatibility, they should not be 
mapped. 

NOTE 4: The X bit towards the IWF is not mapped and shall always be set to ON in 
the data transfer state since there is no flow control in transparent mode. 

NOTE 5: CT 107 is controlled by the channel synchronization process 
{3G TS 27.001 [9]). 

NOTE 6: CT 108/2 may be used in the call setup and answering processes. 

NOTE 7: The status bits are filtered before being mapped to the ITU-T V.24 [17] 
circuits (3G TS 27.001 [9]). 



Table 2: Minimum set of V-series interchange circuits 



Circuit Number 


Circuit Name 


Ground 


Data 


Control 


to 
TE2 


from 
TE2 


to 
TE2 


from 
TE2 


CT102 


Common Return 


X 










CT103 


Transmitted 
data 






X 






CT104 


Received data 




X 








CT105 


Request to 
send 










X 


CT106 


Ready for 
sending 








X 




CT107 


Data set ready 








X 




CT108.2 


Data terminal 
ready 










X 


CT109 


Data channel 

received line 

signal detector 








X 




CT114 


Transmitter 

signal element 

timing 








X 




CT115 


Receiver 

signal element 

timing 








X 




CT125 


Calling in- 
dicator (note) 








X 




NOTE: CT1 25 is used with the AUTO ANSWER function of the TAP. 
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Use of Network Independent Clocking (applicable to GSM only): 

Network Independent Clocking is only applicable to calls using ITC value "3.1 kHz audio ex PLMN". 

Within the GSM network the coding of the values for bits associated with NIC is specified in GSM specifications 
GSM 04.21 [4] and GSM 08.20 [5]. In the forward (transmitting) direction the multiframes shall be coded in exact 
accordance with that specified in those specifications. Bit E6 is set to "1" in alternate modified ITU-T V.llO [22] 
frames at the transmitter. However, the use of this bit at the receiver for monitoring frame Synchronization, or any other 
purpose, is not specified and is left to the discretion of the implementor. 

A "perfect linear block Code" is used in C1-C5, whose error correction properties may be utilized in the receiver, in 
order to ensure reliable operation of NIC. 

The NIC sending function has to recognize when the difference between the applicable clock speed of the GSM 
network and the interface speed generates a positive or negative whole bit requirement. When this positive or negative 
condition occurs, the NIC codewords specified in specification GSM 04.21 [4] are used to transport this condition to the 
receiving NIC function. Transmission of the codeword shall clear the positive or negative condition related to that 
codeword at the sending function. The sending function shall not send more than one positive or negative 
compensations within a contiguous period of time corresponding to 10 000 user data bits minus the number of user data 
bits necessary to make up an even number of ITU-T V.l 10 [22] frames between compensations (NIC compensation is 
coded in two ITU-T V.l 10 [22] frames). This results from the requirements to compensate for maximum clock 
differences of +100 parts per million. If the receiving function receives NIC compensations more often than a 
contiguous period of time corresponding to 10 000 user data bits, there is no guarantee that data will not be lost. 

The NIC receiving function has to provide the capability to support the compensation requirements of the sending 
function. This compensation is managed by manipulating the clock speed of the interface, within the standard 
constraints of that interface. 

Overall, the compensation functions have to be capable of managing clock tolerances of +100 parts per million. 

The NIC function has to recognize and manage the conversion of the NIC information received incoming from an ISDN 
terminal Interface. The conversion has to be made to the NIC format used within the GSM System as defined in 
specifications GSM 04.21 [4] and GSM 08.20 [5]). The NIC function has to manage the conversion of the GSM NIC 
format into that used within the ISDN in the traffic direction towards the ISDN terminal interface. 

Due to the incompatibility between the ISDN and the GSM requirements NIC interworking is nor provided between 
these two formats, as such no NIC function is required in providing interworking to the ISDN for unrestricted digital. 

Action on loss of synchronization: 

If five consecutive NIC multiframes have incorrect framing bit values in E7, the receiver shall stop applying clocking 
compensation to the received data. Resynchronization shall be attempted and compensation shall resume when 
synchronization is achieved. 

Signal element timing: 

Receiver signal element timing (CTl 15) is generated by MT2. In the GSM transparent case, this shall be synchronized 
to the output of RAT function. In the UMTS transparent case, this shall be synchronized to output of the RLC. In the 
non transparent case it is output from the L2R on the basis of the current user data rate. A transition from ON to OFF 
condition shall nominally indicate the centre of each signal element on CTl 04. 

Transmitter signal element timing is generated by MT2 (CTl 14), this may be synchronized to CTl 15. 

In the case of alternate Speech/Group 3 Facsimile, there may be a Channel Mode Modify during the course of the 
facsimile portion of the call. If this occurs, the user data rate changes and this is reflected to the ITU-T V.24 [17] 
interface as a change in the clock speed on CT 1 14 and CT 1 15. 

4.2.1 .1 Multislot configurations (Channel coding TCH/F9.6 or TCH/F4.8 kbit/s) 

In transparent multislot configurations status bits SI, S3 and the X-bit between the D12 and D13 in the 

ITU-T V.l 10 [22] 80-bit intermediate rate frame - are used for transferring substream numbering information. The 

S4-bit is used for frame synchronization between the parallel substreams (ref GSM 04.21 [4]). 
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4.2.1 .2 Channel coding TCH/F1 4.4 and TCH/F28.8 

For information on the mapping of the interchange circuit signalling bits in the 14,5 multiframe structure, refer to 
GSM 04.21 [4]. 

4.2.2 ITU-T X.21 [23] Interchange circuit mapping 

Void. 

4.2.3 Case of ITU-T S-interface 

Void. 

4.3 Call establishment signalling mapping at TE/MT interface 
4.3.1 ITU-T V-series interfaces 

4.3.1 .1 Call establishment manual operation - utilizing Alternate Speech/Data or 
Speech followed by Data Capabilities 

Void. 

4.3.1 .2 Call establishment manual operation - utilizing the Unrestricted Digital 
Capability 

In this case the user shall not hear network supervisory tones or answer tone. The data transfer phase shall be entered 
automatically. 

4.3.1 .3 ITU-T V.25 bis [1 8]auto call/auto answer 

Editor's note: V.25bis is outdated. References to V.25 bis procedures need to be replaced by corresponding 
procedures based on V.250 and 3G TS 27.007. 

The mapping of the ITU-T V.25 bis [18] procedures to the messages of the PLMN Layer 3 signalling 
(3G TS 24.008 [7]) is defined in clause 4. 

Auto Call: 

This procedure is provided according to ITU-T V.25 bis [18] using only circuit 108/2. A subset of ITU-T V.25 bis [18] 
is shown in table 4. This subset gives minimum level of control and indication. 

During the call establishment phase, i.e. after signalling, call tone according to ITU-T V.25 bis [18] shall be generated 
in the IWF, where appropriate. 

Auto Answer: 

This procedure is provided according to ITU-T V.25 bis [18]. 
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Table 4: Minimum set of ITU-T V.25 bis [18] Call Set-up Commands and Indications 





Description 


lASCharacters 


Commands 
from TE2 


Call Request with Number 
provided 0,1. .9,*,#,A,B,C,D 
Disregard Incoming Call 
Connect Incoming Call 


CRN 

DIG 
CIC 


Indications 
toTE2 


Call Failure Indication 

XX = CB,AB,NT,FC(Note) 

INcoming Call 

VALid 

INValid 


CFIXX 

INC 

VAL 
INV 



NOTE to table 4: CB = Local MT busy 
AB = Abort call 
NT = No answer 
FC = Forbidden call (*) 

(*) Forbidden call indication results from contravention of rules for repeat call attempts as defined by the 

appropriate national approvals administration. It is recommended that this is the responsibility of the MT, 
not the TE2. 

4.3.2 ITU-T X-series interfaces 

Void. 

4.3.3 ITU-T S-interface (ITU-T 1.420 [11]) signalling mapping 

Void. 

4.3.4 X.25 Procedures Mapping 

Void. 



5 Terminal Adaptation Functions for synchronous 

non-transparent services. 

5.1 Rate Adaptation and protocol model 
5.1.1 ITU-T R-interface 

For the protocol model and rate adaptation function applied in this case see Models 4b and 4e of figures 6, 7 and 8 in 
GSM 03.10 [2]) and 3G TS 23.910[35]. 



5.1.2 

Void. 



ITU-T S-interface 
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5.2 Signalling IVIapping (GSIVI only) 
5.2.1 Interchange circuit signalling mapping 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 5 shows the mapping scheme between the ITU-T V.24 [17] circuit numbers and the status bits for 
the non-transparent mode. It also shows how the unused status bits should be handled. It is derived from the general 
mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of the status bits by the L2RCOP is described in annex A. 

Table 5: Mapping scheme at the IVIT for the non-transparent mode 



Signal at TE2/MT 

interface or condition 

within the MT 


Mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106{note4) 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


C1 1 08/2 


not mapped (note 6) 




CT109 




from status bit SB 


CT133{note8) 


To status bit X (notes 3,8) 




always ON 


to status bit SA (note 2) 




always ON 


to status bit SB (note 1) 




Ignored by MT 




from status bit SA (note 2) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (27.002, 

annex C), could be used to carry CT 105. However, CT 105 should 

always be ON In the data transfer state since only duplex operation Is 

supported. Also, many DTEs use the connector pin assigned to CT 105 

for CT 133. No Interchange circuit shall be mapped to the SB bit, which 

shall always be set to ON In the data transfer state. 
NOTE 2: The SA bits (both directions) are not mapped since CTs 1 07 and 1 08/2 

are handled locally (notes 5 and 6). 
NOTE 3: The condition of status bit X towards the IWF may also be affected by the 

state of the receive buffer In the MT. 
NOTE 4: The state of CT 106 (or other local flow control mechanism) may also be 

affected by the state of the transmit buffer In the MT and the state of the 

RLP (RR/RNR). 
NOTE 5: CT 107 is controlled by the channel synchronisation process 

(3G TS 27.001 [9]). 
NOTE 6: CT 108/2 may be used In the call setup and answering processes. 
NOTE 7: For Inband local flow control, changes In the condition of the status bit X 

from the IWF also result in the sending of XON or XOFF to the DTE. 
NOTE 8: For inband local flow control, CT 133 is not mapped and the status bit X 

towards the IWF Is controlled by the reception of XON and XOFF 

characters from the DTE. 



5.2.2 Call establishment signalling mapping 

Void. 



5.3 



Flow Control 



The passage of flow control information between L2Rs is described in annex 1 . 
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5.3.1 Conditions requiring flow control towards the network 

The L2R function shall send immediately a "flow control active" indication in the following circumstances: 

(i) if the receive buffer from the radio side reaches a preset threshold; 

(ii) if local flow control is initiated by the TE2 (see subclause 5.3.3 a)). On receipt of this flow control indication 
transmission of data from the receive buffer towards the TE2 is halted. 

On removal of the buffer congestion or local flow control the L2R shall send a "flow control inactive" indication. 

In addition, for the local flow control condition, transmission of data from the receive buffers shall be restarted. 

5.3.2 Conditional requiring flow control towards TE2 

The L2R function shall immediately activate local flow control (see subclause 5.3.3 b)) under the following 
circumstances: 

(i) the transmit buffer reaches a pre-set threshold; 

(ii) the L2R receives a "flow control active" indication. 

On removal of the buffer congestion or receipt of L2R/RLP "flow control inactive" the local flow control shall be 
removed. 

5.3.3 Local flow control 

Only inband flow control is allowed: 

a) from TE2: 

RNR is sent to indicate flow control active. RR is sent to indicate flow control inactive. Where RR/RNR is 
utilized then the TAP shall generate flow control active/inactive immediately. 

b) from TAP: As from TE2. 

where this method is used, the L2R shall pass the RNR/RR frames to the TE2. 

5.4 Buffers 

5.4.1 TX buffers 

Data received from the TE2 shall be buffered such that if the MT is unable to transfer the data over the radio path then 
data is not lost. 

The buffer shall be capable of holding nl bytes. When the buffer is half full, TE2 shall be flow controlled as per 
subclause 5.3.2. The value for nl is up to the implementors. 

5.4.2 RX buffers 

Data for transfer to the TE2 shall be buffered such that if the TE2 is unable to accept data then data transferred from the 
MT is not lost. 

The buffer size should be n2 bytes. The value for n2 is up to the implementors. 

When the buffer becomes half full, the L2R shall send a "flow control active" indication. 
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6 V-series interface procedures to 3G TS 24.008 [7] 

mapping 

Editor's note: V.25bis is outdated. References to V.25 bis procedures need to be replaced by corresponding 
procedures based on V.250 and 3G TS 27.007. 

Interface procedures not directly mappable to 3G TS 24.008 [7] (ie. ITU-T V.25 bis [18] VAL/INV) are not considered. 
Mobile management procedures of 3G TS 24.008 [7] are not considered applicable. 

Mapping of other call establishment or clearing messages to the S interface e.g. "Call proceeding", etc. have not been 
included. It is assumed that these may be mapped directly and thus are of no relevance to the ITU-T V.25 bis [18] or 
manual interface. 



6.1 IVIobile Originated calls 



a) SET-UP. 



Element 


Derived from 


lUIMI 


ITU-T V.25 bis [18] 


ITU-T S interface 






message 


message 


Called Address 


Keypad 


CRN/CRI/CRS 


Setup 


Called 


Keypad 


CRI 


Setup 


Sub Address 
HLC 






Setup 


Derived from internal settings or MMI information. 


LLC 


Same as HLC 


Setup 


BC 


Same as HSC 


Setup (with additional 




3G TS 27.001 [9] gives allowed values 


information from IVIMI 
oriented settings) 



b) RELEASE COMPLETE. 



Element 


Derived from | 


MMI 


ITU-T V.25 bis [18] 
message 


ITU-T S interface 
message 


Cause 


Display (optional) 


CFI 


Release complete 



6.2 



IVIobile Terminated calls 



Call establishment is initiated by receipt of Setup at the MS: 
a) SET-UP. 



Element 


Mapped on to | 


MMI 


ITU-T V.25 bis [18] 
message 


ITU-T S interface 
message 


Called Address 

Called 

Sub Address 

HLC 

LLC 

BC 


Display (optional) 
Display (optional) 

Display (optional) 
Display (optional) 
Display (optional) 


INC 

Not applicable 

Not applicable 
Not applicable 
Not applicable 


Set-up 
Set-up 

Set-up 

Set-up 

Set-up (with PLMN 

specific elements 

removed) 



b) CALL CONFIRM. 

Information for the BC element in the call confirm is derived from e.g. MMI or by internal settings. 

c) CONNECT. 
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Connect is sent in response to connect from the S-interface, CIC from ITU-T V.25 bis [18] or from MMI. 

7 ITU-T X.21 [23] interface procedures to 
3G TS 24.008 [7] mapping 

Void. 

8 Support for packet service 

Void. 
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Annex A (normative): 
L2R Functionality 



A.1 Introduction 



This annex describes the Layer 2 Relay (L2R) functionality required to support LAPB non-transparently. The general 
aspects of L2Rs are described in specification 3G TS 27.001 [9]. Figure 1 shows the three sub-functions of the L2R. 



LAPB 



BORE 



LAPB 
Entity 



L2RB0P 

Entity 



L2RB0P 



LAPB Link Access Protocol Balanced 
BORE Bit Oriented Relay Entity 
L2RB0P L2R Bot Oriented Protocol 

Figure 1 : Sub-functions of the L2R 

Clause 2 describes the L2R Bit Oriented Protocol (L2RBOP) and clause 3 describes the use of the L2RBOP to transport 
LAPB information fields. 



A.2 L2RB0P 



The LAPB user information fields and interface status changes are transferred between L2Rs using the services of the 
radio link. The L2RBOP entity segments and reassembles the LAPB user information fields to fit into the service data 
units (SDUs) handled by the radio link. I.e. segments of LAPB user information fields and interface status changes are 
transferred between L2Rs in n octet Protocol Data Units (PDUs). This corresponds to the fixed length of the RLP frame 
information field. The octets within the L2RBOP-PDU are numbered to n-1, octet is transmitted first. The value of n 
depends on the negotiated RLP version and frame type (3G TS 24.002 [8] ). The bits within the octets are numbered 1 
to 8, bit 1 is transmitted first. 

The RLP version value 2 indicates RLP multi-link operation. The RLP version value or 1 indicates RLP single-link 
operation. 

The L2RBOP also provides facilities for transferring LAPB connection control information between L2Rs. This LAPB 
connection control information allows concatenated LAPB connections to be established, reset and released. 

The L2RBOP PDUs are coded as follows: 

each octet contains a status octet, 1-8 bits of user information, control information or fill; 

octet shall always contain a status octet in case at least one status octet is transportet in the L2RBOP PDU. In 
RLP -versions and 1 a PDU always carries at least one status octet. In RLP version 2 a PDU carries status 
octet(s) only if actual status change(s) has taken place within the period represented by the PDU. Here the L2R 
status flag in the RLP version 2 header is set to 1 when status octet(s) is carried in the PDU; 
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status octets contain 3 status bits and 5 address bits. In cases where two status octets within the PDU are 
separated by more than 23 octets, the first status octet in octet m is followed by a pointer octet in octet m+1 
forming a two-octet status field. The pointer octet contains one reserved bit and seven address bits indicating the 
number of characters between the status field and the second status octet; 

the 3 status bits are used to convey the interface conditions that are conveyed by the S and X bits in ITU-T 
recommendations V.llO [22]. In the case of ITU-T V series interfaces the 3 status bits correspond to SA, SB 
and X bits specified in ITU-T V.llO [22]. The ITU-T V series SA, SB and X bits use bit positions 8, 7 and 6 
respectively in the status octets. The ITU-T X series S and X bits use bit positions 7 and 6 respectively, in this 
case bit position 8 is unused; 

LAPB user information is carried in L2RBOP-PDU information octets such that the first LAPB user information 
bit, in any consecutive group of 8, received or transmitted corresponds to bit position 1 in the octet. The second 
to bit position 2, etc.; 

information octets are inserted into the L2RBOP-PDU in order of arrival in octets 1 to n-1 for RLP single-link 
operation, in octets 1 to n-1 for RLP multi-link operation with status octet transportation and in octets to n-1 
for multi-link operation with no status octet transportation; 

the address field in the status octets indicates the position of the next status octet within the L2RBOP-PDU. This 
indicates the number of information octets between status octets. Thus if two status octets are inserted into an 
L2RB0P-PDU at offsets 1 and m the address field value for the status octet at offset 1 shall be defined by m-1-1 
(m>lH-l). The low order bit of the address corresponds to bit 1 of the octet and the high order bit to bit 5; 

status octets are inserted in the information stream whenever a status change needs to be transmitted; 

only address values 1 to n-2 (n-2 < 23) in the address field of status octets are used for addressing purposes. The 
implication of not allowing address value to be used for addressing is that two status octets can not be sent 
after each other. The remaining codes are used to indicate: 

last status change, remainder of L2RBOP-PDU is empty. Address field value is 3 1 ; 

last status change, remainder of L2RBOP-PDU full of information octets. Address field value is 30; 

end of a LAPB user information field. Address field value is 29. This is used to delimit LAPB user 
information fields. In this case the 3 status bits do not have their usual meaning. They are used to indicate the 
number of information bits in the previous information octet. A binary number in the range to 7 is 
contained in bit positions 8, 7 and 6, bit 6 is the low order bit. The values 1-7 indicates the number of 
information bits used, value indicates all bits used. If this octet is not on the last position in a 
L2RBOP-PDU another status octet follows (e.g. an End of LAPB user information field in octet is followed 
by a status octet in octet 1); 

abort a LAPB user information field transfer. The address field value is 28. This is used to abort the 
transmission of a LAPB user information field after sending one or more segments in L2RBOP-PDUs. If this 
octet is not on the last position in a L2RBOP-PDU another status octet is following (e.g. an Abort a LAPB 
user information field transfer in octet is followed by a status octet in octet 1); 

- L2RBOP-PDU contains at least two status octets which are separated by more than 23 characters; the 

address-field value in the first octet of the two-octet status field is 27 and the address bits in the pointer octet 
of the status field indicate the number of characters between the two-octet status field and the next status 
octet. 

address field values from n-1 to 26 are reserved. In case of a PDU more than 25 octets in length, address field 
values from 24 to 26 are reserved. When it is necessary to insert a status octet into the information stream when 
no status change has occurred, e.g. to indicate that the remainder of an L2RBOP-PDU is empty or to indicate end 
of a LAPB user information field, the current status shall be repeated; 

in case when 64 data octets are carried by a 66-octet PDU, a status octet is carried in octet and another status 
octet within the first 24 data octets. (The first status octet gives the address of the second status octet, which 
carries value 30 in its address field); 
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LAPB connection control information is transferred between L2Rs by use of a connection control PDU. 
Connection control PDUs consists of an L2RBOP PDU with the status octet in octet containing address field 
value 0. The coding of the remainder of the L2RBOP connection control PDU is as follows: 

octet 1 contains the connection number, always for LAPB. Other values are reserved for future use; 

octet 2 contains the connection control information. The connection control information values are 1 for 
Connect, 2 for Reset, 3 for Disconnect and 4 for loss of LAPB interframe fill. This octet is coded as a binary 
number with the low order bit corresponding to bit 1 ; 

the use of octets 3 to n-1 is reserved. 

LAPB exchange identification frames (XID) are transferred between L2Rs by use of exchange identification 
PDUs. These PDUs consist of L2RBOP PDUs with the status octet in octet containing address field values 0. 
The coding of the remainder of the PDU is as follows: 

octet 1 contains the connection number, always for LAPB. Other values are reserved for future use; 

octet 2 contains the exchange identification indication. The values are 5 for an Exchange Identification 
Request and 6 for an Exchange Identification Acknowledge. The values 7 to 255 are reserved. This octet is 
coded as a binary number with the low order bit corresponding to bit 1 ; 

the octet 3 contains a normal status octet. The rest of the PDU and of the following PDUs, if any, is used to 
transfer the XID information and it is treated like normal user data information PDUs as far as the coding is 
concerned. 



A.3 Use of the L2RB0P 



The L2R function required to support LAPB non-transparently consists conceptually of the three sub-functions shown 
in figure 1, i.e. the LAPB entity, the BORE and the L2RB0P entity. These perform the following functions: 

LAPB entity - This terminates the LAPB protocol from the terminal or the network. The service provided by the 
LAPB entity to the BORE is described in ISO DIS 8886.2 [32] - OSI Data link service definition; 

L2RBOP entity - This uses the services provided by the radio link, see specification 3G TS 24.022 [8]. The 
service provided by the LAPB entity to the BORE; 

BORE - This concatenates the data link services provided by the use of the L2RBOP and LAPB. 

The functions are described in more detail in the following subclauses. 

A.3.1 Radio Link Connection Control 

The L2RB0P entity uses the services of the radio link to establish, reset and release the connection to its peer L2RB0P 
entity. The radio link connection shall be established and released as a result of indications from the signalling 
mechanisms when the supporting circuit switched connection is established. 

After an RLP reset or RLP disconnect the L2RBOP entities shall assume that the remote LAPB connection is in 
disconnected state. No data can therefore be transported between the L2RBOP entities before an exchange of the 
connection control PDU "Connect" has taken place. All connection control PDUs transferred before the RLP reset are 
no longer valid and must not be acknowledged. All PDUs (except XID) received by the L2RBOP entities after an RLP 
reset or disconnect and before a new connection control PDU "Connect" has been received shall be discarded by the 
L2RBOP entity. 
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A.3.2 Status transfer 

The L2RBOP entity transfers interface status information between L2Rs via the status octets in the L2RBOP-PDUs. 
The meaning of the bits is exactly the same as that defined in ITU-T recommendation V.l 10 [22]. Status changes are 
inserted in the L2RBOP-PDU in the position corresponding to the position in the information stream at the DTE/DCE 
interface that the interface status change occurred. When the RLP is established or reset a L2RBOP-PDU with the 
current status octet shall be sent. 

A.3.3 LAPB connection control 

The L2RBOP entity transfers LAPB connection control information between L2Rs via the L2RBOP connection control 
PDUs. This allows a LAPB connection to be established, reset and released when the remote LAPB connection is 
established, reset and released or vice versa. L2RBOP connection control PDUs containing connect or reset requests 
shall be acknowledged by a similarly coded L2RBOP connection control PDU in the reverse direction. Data transfer 
between L2Rs is not allowed until the connection control acknowledge PDU is received. 

In the case of requests crossing they shall each be treated as acknowledgements of the other. 



A.3.4 LAPB exchange identification 



The L2RB0P entity transfers a LAPB exchange identification request/acknowledge between L2Rs via the L2RB0P 
exchange identification PDUs. This allows transfer of identification information prior to link establishment and/or 
during the link (especially with respect to ISO 8885 [31]/DADI). A L2RB0P exchange identification request PDU shall 
be answered by an associated exchange identification acknowledge PDU. In case of crossing of two requests each 
request shall be answered individually. A LAPB exchange identification request with identification information shall be 
acknowledged by the LAPB entity from L2R only when the acknowledge from the remote LAPB connection is 
indicated by an exchange identification acknowledge PDU sent by the remote L2RBOP entity. 

A.3.5 Data Transfer 

The L2RB0P entity assembles and disassembles L2RBOP-PDUs by segmenting and reassembling the LAPB user 
information fields. 

A.3.6 Flow control 

Flow control information is transferred between L2Rs in two ways, these are: 
- back pressure caused by L2R buffer conditions; 
use of the X-bit in the status octet; 
X = 1 flow control active; 
X = flow control inactive. 
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